Developer CD Series 1997 January: Mac OS SDK/Dev.CD Jan 97 SDK2.toast/Development Kits (Disc 2)/OpenDoc Development Framework/ODF-Interest Archive/June 96/Re Extension Link Problem

Internet Message Format | 1996-12-03 | 3.3 KB | [TEXT/ttxt]

Subject:     Re:Extension Link Problem
Sent:        6/7/96 8:37 AM
Received:    6/7/96 8:51 AM
From:        Greg Friedman, [e-mail]
Reply-To:    ODF Interest, [e-mail]
To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.

At 10:19 AM 6/7/96, Doyle Rhynard wrote:>     I am having a problem with
linking a client part when I reference an
> extension defined in another part. This the IDL file that I am using to
> define the extension, TestExt:
>
>   #ifndef TestExt_IDL
>     #define TestExt_IDL
>

The problem you describe is caused by the fact that the linker cannot find
the class data symbol for your client's extension. There are two solutions
for the problem; one is better than the other.

The less preferable solution is to link your client part against your
server part's shared library. For this to work, you must make sure that
your extension's class data symbol is exported from your server part, by
adding the line:

ADI_TestExtClassData

to your server's .exp file. Make sure you REMOVE any of the specific
methods implemented by your extension from your server's .exp file. In the
SOM world, only a class data symbol should be exported, not method names.

This solution has two shortcomings:

1). SOM, as it is specified, really wants just one definition of a specific
class name per machine. If you create multiple part editors, each of which
can serve the same extension, and statically link the extension's
definition into each part, you have introduced multiple definitions of the
extension. In simplistic terms, you can think of SOM as providing an object
factory. When you try to instantiate an instance of a particular class, SOM
looks up the implementation of the class by name, and creates and returns
an instance. Multiple part editors that each implement the same extension
muddle this model, and SOM won't necessarily instantiate the correct
implementation. It happens that the current Mac implementation of SOM has
optimizations that have a side-effect of eliminating collision problems in
most cases. Your specific use case will not have a collision problem.
Still, since the SOM spec doesn't support it, you're better off in the long
term if you avoid the problem now.

2). Once you've distributed multiple part editors that use your extension,
you'll have to update each part editor for it to get any fixes you make to
your extension. In other words, if you write SurfWriter and SurfDraw, each
of which statically link your SurfsUp extension, and later release a new
version of SurfDraw that has an updated SurfsUp extension, SurfWriter will
not get the SurfsUp fixes.

The better solution to your problem is this:

Create a new shared library that implements only your extension. From this
shared library, export only the extension's class data, as described in the
first solution. Link both your client and your server parts against the new
shared library.

With this model, any server part that provides the extension will always
provide the same version and implementation. You can upgrade the extension
without having to touch all of the server parts that provide it. And,
finally, you avoid instantiation collisions.

gsf.


_________________________________________________________
Greg Friedman      ODF Engineering       Apple Computer